Testing of memory arrays, whether embedded within a processor die or external to the processor die, typically requires command, control, and test data to be generated by testing equipment or extensive logic within, or associated with, the device under test (DUT). Commands (e.g., read, write, etc.) typically involve operations to be executed by some state machine or processor within the DUT in order to interact with the memory array. Control typically involves memory addresses or other signals that place the memory array or interfacing logic in a particular state in order to interact with the memory array. Data usually refers to the actual information (normally in bit format) programmed into or read from the memory array.
In order to test the DUT at speeds similar to those under normal operating conditions, testing equipment typically must operate beyond its capability. As a result, the array may not be tested under normal operating conditions, which may result in defects within the array going undetected. In the case in which extensive logic is used within, or at least associated with, the DUT to generate testing command, control, and data, processor power and/or real estate budgets may be compromised in order to accommodate the testing logic.
FIG. 1 illustrates a prior art memory array testing architecture in which algorithmic pattern generation (APG) logic within the testing equipment is used to generate command, control, and data necessary to test the DUT. In FIG. 1, control, command, and data generated by the testing equipment may be input to the DUT on parallel inputs and translated into a format compatible with the internal bus interface. The translated control, commands, and data may then be transmitted across the internal bus of the DUT where it is further translated within the bus-to-array interface into the test pattern to be applied to the memory array.
In the prior example illustrated in FIG. 1, APG logic within the testing equipment is used to generate the command, control, and data necessary to test the memory array within the OUT. Because memory testing equipment is not typically able to test memory arrays at the speeds at which they are accessed (read or programmed) under normal operating conditions, the testing architecture of FIG. 1 can be deficient in its test coverage.
FIG. 2 illustrates a prior art testing architecture in which a controller located either within, or otherwise associated with, the DUT is used to generate the command, control, and data necessary to test a memory array within the DUT. In testing architectures, such as the one illustrated in FIG. 2, the testing equipment is typically required to generate relatively minimal control information to the DUT, with which logic located within the DUT may generate command, control, and data necessary to test the memory array within the DUT. The control information supplied by the tester, in this case, is minimal and therefore may be input to the DUT via a serial interface, which requires fewer pins to be allocated for testing purposes than the parallel inputs illustrated in FIG. 1. The serial data may then be converted within the DUT to parallel data required by the command, control, and data generation logic.
In the prior art example illustrated in FIG. 2, extensive logic, may be necessary to generate the necessary command, control, and data information to test the memory array of the DUT, as the logic must substantially replace the APG logic of the testing equipment. Because the logic is located within the DUT, however, the memory array may be tested under conditions substantially similar to those of normal operating conditions, thereby improving DUT testing coverage.
The command, control, and data generation logic illustrated within FIG. 2 typically requires large sequences of programming information to test the memory within the DUT. For example, one common testing sequence programs and reads data within the memory array at substantially incremental addresses. FIG. 3 illustrates a programming sequence that may be used to configure the prior art command, control, and data generation logic of FIG. 2 to perform a test pattern in which data is programmed to and read from incremental addresses within a memory array within the DUT.
The program sequence of FIG. 3 illustrates six operations (^(wD1), ^(rD2, wI3), ^(rI4, wD5), v(rD6, wI7), v(rI8, wD9), v(rD10)), that must be successfully programmed into the prior art command, control, and data generation logic of FIG. 2 before the command, control, and data generation logic will begin to issue the program sequence to the memory array to be tested. In the program sequence of FIG. 3, the command registers of the prior art are programmed to write an initial data to various memory locations, where “W” represents a write operation, “D” represents an initial data to be written, and “1” represents the operation number (number “1” in this case). Next (operation “2”), the data written from the previous operation (“D”) is read (“r”), and erased by writing the inverse value (“I”), and the address is incremented (“^”). Operations 2 and 3 can then be repeated for all address locations being tested.
Once the programming sequence of FIG. 3 is programmed into the registers of the command, control, and data generation logic of FIG. 2, they may be sequentially issued to the memory array to be tested within the DUT via the flow control logic illustrated in FIG. 2.
Requiring lengthy programming sequences to configure the command, control, and data generation logic of the prior art can require extensive logic, programming registers, and overhead, requiring substantial processor real estate and power. On the other hand, the prior art alternative illustrated in FIG. 1, wherein tester equipment is used to generate command, control, and data necessary to test the memory array within the DUT does not typically allow the memory array to be tested at speeds consistent with those of normal operating conditions.